왜 팩토리 패턴을 적용했는가?
스케줄링 되는 배치를 개발 중이었다.
기존 배치(General)가 주기적으로 Source DB에 데이터를 이관하고 있었다. 이후 추가 배치를 개발 해야 되는 상황이 왔다.
언제나 그랬듯이 항상 수정 및 추가 개발 건이 생긴다.
추가로 배치를 개발 해야 하는 것은 데이터 무결성을 체크하는 비교 배치, 적재 실패된 데이터를 Retry하는 Retry배치 였다.
여기서 가장 먼저 든 생각은 아… 코드 중복이 생기겠구나 였다. 각각에 유형이 조금씩 다를 뿐 배치는 어차피 read, process, write 이기 때문이다.
그래서 디자인 패턴 및 객체지향적으로 코드를 작성해봐야 겠다. 라는 다짐이 리팩토링 및 디자인패턴 적용에 시초가 되었다.
가장먼저 생각이 드는 부분은 코드 중복을 최소화 하기 위해 공통적인 배치는 추상클래스로 만들어 놓고 각각에 입맛에 맞게 구상 배치 클래스를 두는 구조였다.
추가적으로 나는 배치 객체를 생성할 때 read, process, write 를 담당하는 각 객체들 또한 framework 화 하여 한꺼번에 객체를 생성하게끔 하여 나 말고 다른 개발자들이 또 새로운 배치를 만들어야 할 때 한가지 팩토리 클래스만 인스턴스하면 해당 배치를 사용 할 수 있게 하고 싶었다.
그랬다, 그래서 추상 팩토리 패턴을 선택하게 되었다.
그래서 내가 직접 사용해본 소감은?
추상 팩토리에 장점중에 하나는 클라이언트 코드에서 여기저기서 객체를 생성하는 코드가 퍼져있는 것을 다시 말해 변화되기 쉬운 코드 부분을 객체 생성을 담당하는 클래스(팩토리)를 만들어 놓으므로써 코드 수정을 한곳에서 할 수 있고 인터페이스, 추상클래스로 다형성을 활용하여 유연한 코드를 할 수 있다는것이 장점이라고 생각한다.
사실, 내가 실무에 적용한 팩토리 패턴에 큰 장점을 가질수 있는 상황은 아니었다.
배치 객체를 생성하는 코드 부분이 고작 각 배치별로 1개씩 밖에 없고 (배치라는 개발 특성인거 같다.) 한번 배치를 생성하면 다신 생성 할 필요가 없기 때문에 배치 객체를 생성하는 일이 그렇게 많지도 않다.
하지만 나는 배치와 배치를 생성하는 팩토리 배치 구조로 실무에 적용해봄으로써 디자인패턴을 하나하나 적용하면서 피부로 느껴 머릿속에 장기기억으로 남기고 싶어 적용해 본 것이다.
그렇다고 팩토리 패턴에 아예 효과를 보지 않았다는 소리는 아니다. read, process, write 에 대한 객체를 하나의 framework 역활을 한 것은 나이스했다고 생각한다.
그래서 언제 사용하면 좋을까?
객체를 인스턴스하는 코드가 클라이언트에서 많이 이용되고 자주 변화가 이루어진다면 팩토리 패턴을 사용하기 적합하다고 생각한다.
다른 유용한 패턴을 적용해 볼게 있다면?
배치 객체안에 reader, processor, writer 를 담당하는 각 객체가 있는데 그 step들이 끝날때 마다 결과 데이터를 갱신해주는 결과 객체를 반환하고 싶은데 이것을 옵저버 패턴을 이용하면 좋을 것 같다는 생각이 들었다.
그래서 다음 포스팅은 옵저버 패턴을 활용한 포스팅을 올리도록 하겠다.
